home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 #1 / Ham Radio 2000.iso / ham2000 / packet / p_g8bpq / bpq_misc / misc-apr.92 < prev    next >
Encoding:
Text File  |  1992-04-17  |  15.0 KB  |  371 lines
  1. **********************************************************************
  2.            * * * * C:\SYSOPS\LTRS\WF5E.LTR * * * * 
  3. **********************************************************************
  4. -
  5.  
  6. From   : WF5E
  7. To     : W6GO
  8. Date   : 31-Mar-1992
  9. Time   : 0537Z
  10. Subject: BPQ
  11. Size   : 608
  12.  
  13. Hi Jay, nice to talk to you the other day. Sorry UPS lost last months
  14. disks. I have enclosed to you two files. One is the BPQCFG.TXT we use 
  15. here on my node and another file on BPQ tips. I hope this helps someone
  16. out. We have used BPQ here for over a year with excellent results.
  17. We have the valley, San Antonio, Houston, Austin, ElPaso connecting to
  18. us and we inturn connect this all the W5XJ in Dallas. We are linked
  19. via NetRom, two meter digis, Texnet wireline...From Phoenix to Shreveport,
  20. La. And also have the HF link comming in from Houston. Well cul all
  21. at Dayton, looking forward to the yearly trip..
  22. De Les 
  23.  
  24. <<<Thanks!  Your files are now included in BPQINFO.ZIP.>>>
  25.  
  26.  
  27.  
  28. Date: 04-05-92 (21:00)              Number: 824 of 838
  29.   To: W6GO                          Refer#: NONE
  30. From: K4CEF                           Read: 04-05-92 (22:04)
  31. Subj: CLEVER!                       Status: RECEIVER ONLY
  32. Conf: GODISK (1)                 Read Type: GENERAL (+)
  33.  
  34. Well, as advertised, reversing the interrupt vectors at the end of
  35. the DEDHOST statements seems to have worked wonders! That was a very
  36. clever suggestion--have forwarded it to a few other Sysops here who
  37. have been wondering the same thing...Have also told them to be sure
  38. and NOT include SWITCH in the NORECOVR.LST file.
  39.  
  40. Also, the little command files are clever--would not have thought to use
  41. the connect scripts in that manner! Now, you see, we will have another
  42. file of helpful hints and kinks to add to the already-confused masses
  43. who read the BPQinfo files!! Thanks, Jay...will keep you posted...
  44.  
  45. 73, Bart
  46.  
  47.  
  48.  
  49. Date: 04-06-92 (05:02)              Number: 827 of 838
  50.   To: W6GO                          Refer#: NONE
  51. From: VE7CQD                          Read: 04-06-92 (19:56) HAS REPLIES
  52. Subj: G8BPQ 4.05                    Status: PUBLIC MESSAGE
  53. Conf: GODISK (1)                 Read Type: GENERAL (+)
  54.  
  55. April 6, 1992
  56.  
  57. Jay,
  58.  
  59. As you know, I have received the G8BPQ switch version 4.05.  I thought
  60. that I would pass along some experiences of our conversion from version
  61. 4.04E.
  62.  
  63. First of all, I would like to say that there two new options in 4.05
  64. that I found made it very worthwhile upgrading.  They are:
  65.  
  66. 1. Option of elimiating the null characters that are sent to the users
  67.    every 11 minutes (AUTOTIMER).
  68.  
  69. 2. Soft DCD.
  70.  
  71. First, disabling the autotimer.  These characters were sent to the
  72. users via the DEDHOST drivers.  Therefore, you just add the parameter N
  73. to the end of your command string when you load the DEDHOST driver.
  74. However, the README.1ST file says:
  75.  
  76.     "Using the first BPQHOST port with the DX Cluster may cause
  77. problems.
  78.      Changing the DEDHOST line to DEDHOST 31 2 1 ......, and changing
  79.      SYSOP.DAT to define only 31 ports, seems to fix it."
  80.  
  81. So, this is how we load our drivers:
  82.  
  83.  DEDHOST 31 2 1 60 255 N
  84.  DEDHOST 31 33 1 30 254 N
  85.  
  86. (the 30 is to save memory) and our SYSOP.DAT:
  87.  
  88.  SET/TNC1 DRSI 31
  89.  SET/TNC2 DRSI 31
  90.  
  91. and we make sure the following are set in BPQCFG.TXT:
  92.  
  93.  ENABLE_LINKED=N
  94.  IDLETIME=0
  95.  MAXCIRCUITS=128
  96.  
  97. Note that we have the above set, whether the hardware is 1 DRSI, 2
  98. DRSI's or a single PK232.  The switch will fool the cluster into
  99. thinking it has more than 64 streams and 2 DRSI's available.  Please
  100. also note that we sometimes experience some problems when we get to
  101. around 33 or 34 streams.  I don't know if we have something set wrong,
  102. or if this is a real bug.  The users connecting to the higher streams
  103. see to get ignored until a recover happens, and then later get ignored
  104. again, even though the stream exists.
  105.  
  106. The next nice feature is SOFTDCD.  I could not find any clear
  107. documentation on this, but in a note from G8BPQ to me, John states "IT
  108. SIMPLY ALLOWS OPERATION WITHOUT SQUELCH".  This only works on DRSI's
  109. and other HDLC plug-in cards.  So, in the PORTS section, add the
  110. statement:
  111.  
  112.  SOFTDCD=1
  113.  
  114. And, now you get a free DCD mod.  We had the hardware mod on 2 radio
  115. ports, and we wanted to upgrade the others, as it worked so well.  Now
  116. we are running open squelch on all radios.  Users used shorter
  117. TXDELAYS, weaker stations pop through, and collisions are less.
  118.  
  119. The only thing that I didn't like is what 4.05 did to the OS/2 Version
  120. 2.0 that I am experimenting with.  I can no longer load DEDHOST into
  121. high virtual memory.  But, I am very satisfied in that I found out what
  122. I can do to OS/2 to prevent it from crashing my PacketCluster session
  123. (for those experimenting with OS/2, never go into full-screen mode - is
  124. no need to anyway).  If my experimenting goes well, I hopefully will be
  125. able to convert lots of sysops from DOS and Desqview to OS/2.
  126.  
  127. Enough rambling.  Hope all goes well with everyone's conversion.  If
  128. anyone knows how to fix our >> than 30 some streams problem, let us
  129. know.
  130.  
  131. 73, Fred VE7VT (and trusted sysop of my VE7CQD node, Lee VE7CC)
  132.  
  133.  
  134. Date: 04-06-92 (19:56)              Number: 829 of 838
  135.   To: VE7CQD                        Refer#: 827
  136. From: W6GO                            Read: NO
  137. Subj: G8BPQ 4.05                    Status: PUBLIC MESSAGE
  138. Conf: GODISK (1)                 Read Type: GENERAL (+)
  139.  
  140. Hi Fred..
  141.    Thanks for the message re BPQ 4.05.  I think your problem with the
  142. streams in the 30 area are contention with outgoing connects which start
  143. at the top end and work down.  Try this and see if it fixes the problem:
  144.  
  145.    Define the DEDHOST which has the lower BPQ streams as PacketCluster
  146. TNC/2 by specifying interrupt 254 (FEh) and define the DEDHOST with the
  147. upper BPQ streams as interrupt 255 (FFh).  Now the incoming connects
  148. will come in on TNC/2 to PacketCluster and overflow onto the lower
  149. streams of TNC/1.  Your outgoing connects will always start at the high
  150. end of TNC/1 so the contention won't occur until you have 60 connects or
  151. so.
  152.  
  153.    Hopefully by that time BPQ and AK1A will be talking better to each
  154. other, maybe without the need for a BPQ host.
  155.  
  156.    This is just conjecture on my part based on some experimentation I
  157. have been doing here on a standalone node.
  158.  
  159.    If you try this, please give some feedback!
  160.  
  161.     73, Jay
  162.  
  163. Date: 04-07-92 (01:53)              Number: 830 of 838
  164.   To: W6GO                          Refer#: NONE
  165. From: K4CEF                           Read: 04-07-92 (03:44)
  166. Subj: MISC                          Status: RECEIVER ONLY
  167. Conf: GODISK (1)                 Read Type: GENERAL (+)
  168.  
  169. Well, W8ZF now has BPQ 405 up and running--and says to tell you that
  170. the SOFTDCD does NOT work for long with the radios squelch turned on--
  171. he tried it last night, says keying rate for the radios got slower and
  172. slower--finally, just did not key at all, and all his users timed out!
  173. I confess I did not try it that long--so that may be the datapoint
  174. you were looking for...your fix on the outgoing streams is wonderful--
  175. have 32 users right now, and I can get an outgoing stream any time I
  176. need one!
  177.  
  178. I cannot believe what a good afternoon and evening I've had DXwise--
  179. worked VP8CBA on 10m CW at lunchtime, then on 20m CW and 40m CW since
  180. I got home--he was a new band country on all but 20.  Just now worked
  181. S9AGD on 80m for a new one there--and worked A71BY on 20m fone in
  182. between.
  183.  
  184. Jeez--one of my users says I am not supposed to have this much fun
  185. once I have worked them all! (Even worked a ZA on 20m CW--but it
  186. was just another ZA)
  187.  
  188. 73, Bart
  189.  
  190.  
  191.  
  192. Date: 04-15-92 (23:43)              Number: 838 of 838
  193.   To: W6GO                          Refer#: NONE
  194. From: K4CEF                           Read: 04-16-92 (02:09)
  195. Subj: BPQ STUFF                     Status: PUBLIC MESSAGE
  196. Conf: GODISK (1)                 Read Type: GENERAL (+)
  197.  
  198. Jay, was going to write up something for the BPQ info, but it certainly
  199. looks like your new file covers the waterfront.  The only thing it
  200. doesn't mention is that one should be sure and NOT put SWITCH in the
  201. NORECOVR.LST file...that seemed to stop my loss of Stream 32 outgoing
  202. connect.
  203.  
  204. Your trial fix of swapping the interrupt addresses around has worked
  205. perfectly -- no more problems with lack of streams on outgoing connects.
  206.  
  207. I've got about 10+ days of continuous uptime with 405, and
  208. no anomalies yet--really looks good.  I do understand the guys who are
  209. using the TNC2 stuff in KISS mode are having a problem with 405, so I
  210. hope that will be easy to solve.
  211.  
  212. See you in Dayton...
  213.  
  214. 73, Bart
  215.  
  216.  
  217.  
  218. Date: 04-03-92 (19:17)              Number: 1248 of 1275
  219.   To: SYSOP                         Refer#: NONE
  220. From: G3WGV                           Read: 04-03-92 (19:46)
  221. Subj: COMMENT (1)                   Status: RECEIVER ONLY
  222. Conf: MAIN BOARD (0)             Read Type: GENERAL (+)
  223.  
  224. Hi Jay,
  225. I uploaded version 4.05 BPQ. I think this is the version you already
  226. have, but just in case...
  227. Yes, I'm thinking of using BPQ myself, but you are right... the
  228. fragmented ducumentation is a real pain. Maybe when I understand it I'll
  229. write something as well!
  230.  
  231. 73,
  232. John
  233.  
  234.  
  235. Date: 04-05-92 (15:57)              Number: 1254 of 1275
  236.   To: K4CEF                         Refer#: NONE
  237. From: W6GO                            Read: 04-05-92 (19:56)
  238. Subj: BPQ                           Status: RECEIVER ONLY
  239. Conf: MAIN BOARD (0)             Read Type: GENERAL (+)
  240.  
  241. Hi Bart..
  242.    Well, the swap of the software interrupts works fine.  Users come in
  243. on what PacketCluster calls TNC/2.  However, there is a small problem
  244. which you may run into!
  245.  
  246.    If you loaded the following:
  247.      dedhost 32 1 1 35 254
  248.      dedhost 31 33 1 35 255
  249.  
  250.    This puts 32 streams in the PacketCluster TNC/2 and 31 streams in the
  251. PacketCluster TNC/1.  The fix is to make the TNC/2 dedhost
  252. (interrupt 254) equal in streams to the number of streams defined by the
  253. PacketCluster SET/TNC/2 statement, and of course the same for TNC1.  I
  254. found that with 32 streams defined in the dedhost and only 31 defined in
  255. PacketCluster, that a 32nd connect could be made to the BPQ code, but
  256. the user would not get anything beyond the connect acknowledgement
  257. "Connected to...".  It was very strange until I figured out what I was
  258. doing to myself!
  259.  
  260.    More on the failure condx.  Just bring up node, no connects, nothing.
  261. Attach/2 1 W1ABC<enter>.  ESCcSWITCH <enter>. F1.  Locks up node!  You
  262. don't have to do a connect at all to demonstrate the problem.
  263.  
  264.    How does the soft DCD work?  Have you tried it?  The MH is really
  265. nice.  We need to come up with a list of commands that Dick can
  266. implement for us so we can look at BPQ screens easily!
  267.  
  268.     73, Jay
  269.  
  270. PS.. Download CEF1.  It has some little files in it you may find useful.
  271.      You might even want to assign a function key to call some of these
  272.      command files..
  273.  
  274.  
  275. Date: 04-08-92 (22:10)              Number: 1265 of 1275
  276.   To: ALL                           Refer#: NONE
  277. From: N4UCK                           Read: (N/A)
  278. Subj: BPQ                           Status: PUBLIC MESSAGE
  279. Conf: MAIN BOARD (0)             Read Type: GENERAL (+)
  280.  
  281. Having some trouble getting BPQHTNC2 to work in the new release 4.05.
  282. All the utils worked fine under old version, but new version, nada.
  283. Running 40MHZ 386, bpq, then DV and PACKCLUS in DV window with DEDHOST.
  284. Have tried BPQHTNC2 both insode and out side of DV.  Always - can't find
  285. switch, any one else havong that problem? Any help?
  286. 73, Jim
  287. N4UCK
  288.  
  289. Date: 04-10-92 (17:54)              Number: 1266 of 1275
  290.   To: ALL                           Refer#: NONE
  291. From: W6GO                            Read: (N/A)
  292. Subj: MORE ON BPQ                   Status: PUBLIC MESSAGE
  293. Conf: MAIN BOARD (0)             Read Type: GENERAL (+)
  294.  
  295. I've posted a fragmented file GO-BPQ.TXT in the BPQINFO.ZIP file which
  296. outlines my experiences with the BPQ code.  There will be more to
  297. follow, but if you are getting started or if you are already running the
  298. code, you may find something in there of use.
  299.  
  300. Download BPQINFO.
  301.  
  302. 73, Jay
  303.  
  304. Date: 04-13-92 (19:26)              Number: 1269 of 1275
  305.   To: SYSOP                         Refer#: NONE
  306. From: G3VMW                           Read: 04-14-92 (06:56) HAS REPLIES
  307. Subj: COMMENT (1)                   Status: RECEIVER ONLY
  308. Conf: MAIN BOARD (0)             Read Type: GENERAL (+)
  309.  
  310. Hi Jay,
  311. I have modified the October 1991 letter describing how to set up BPQ and
  312. PacketCluster and uploaded in the file BPQSETUP.ZIP.  I hope it helps a
  313. little bit.  I was pleased to get a data throughput of 1829 cps which
  314. sure moves the files in/out of the DX-BBS.  I will upload the GB7YDX
  315. info for April later in the month the same way.  73 de Steve G3VMW
  316.  
  317. Date: 04-14-92 (06:56)              Number: 1271 of 1275
  318.   To: G3VMW                         Refer#: 1269
  319. From: W6GO                            Read: NO
  320. Subj: COMMENT (1)                   Status: RECEIVER ONLY
  321. Conf: MAIN BOARD (0)             Read Type: GENERAL (+)
  322.  
  323. Thanks for the updated file!  I'll try to get some time and compare it
  324. with the original to see what you have changed.  73, Jay
  325.  
  326.  
  327. Date: 04-16-92 (07:19)              Number: 841 of 841
  328.   To: VE7CC                         Refer#: 840
  329. From: W6GO                            Read: NO
  330. Subj: BPQ PROBLEMS AT VE7CQD        Status: RECEIVER ONLY
  331. Conf: GODISK (1)                 Read Type: GENERAL
  332.  
  333. -> Hi Jay,
  334. ->
  335. -> I have sad news to report on the fix you gave me. Streams 1-29 of
  336. -> TNC2 worked fine for incoming connects. The next 2 users on streams
  337. -> 30 and 31 didn't get logon messages, or have their usercmds
  338. -> executed, but eventually they were RECOVERED and all seemed to work
  339. -> ok after that for them.
  340. For the info of others reading this, the "fix" is my suggestion that the
  341. first DEDHOST should be set up on the first used BPQ streams and
  342. assigned as TNC/2 to PacketCluster by using software interrupt 254
  343. (FEh).
  344. ->
  345. -> The next user was assigned stream 1 of TNC1 and had exactly the same
  346. -> results. The next 2 users were assigned streams 2 and 3 of TNC1 and
  347. -> they were treated fine.  Got logon messages and everything worked
  348. -> 100%.
  349. ->
  350. -> The next user didn't make it to the cluster.  He got the message -
  351. -> Attached to remote sysop system - enter password   etc. He didn't
  352. -> show up as being assigned a stream.  He had tried to connect to
  353. -> VE7CQD, so he shouldn't have ended up there.  When he entered SH/U he
  354. -> was given the message RETURNED TO DXWHO  (Our alias for
  355. -> VE7CC-3).  He never did get to the cluster.
  356. ->
  357. -> That was the last user who needed those higher streams for tonight.
  358. -> After that other users started disconnecting and new users on their
  359. -> streams seemed to work fine. Seemed to work better than before, as
  360. -> none of these users would have gotten anything then.  But still a
  361. -> long way from working properly. Am running 60K of buffers for TNC2
  362. -> and 40K for TNC1 Ready for next fix!
  363. ->
  364. -> 73 de Lee
  365. -> VE7CC (SYSOP of VE7CQD)
  366.  
  367. Wow!  We have lots to learn with this code.  K4CEF has had excellent
  368. luck with the software interrupt assignment I suggested.  Now, we need
  369. to find out what is different between VE7CQD and K4CEF!
  370.     73,  Jay
  371.